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PATENT 

METHOD AND DEVICE FOR MONITORING DATA TRAFFIC AND PREVENTING 
UNAUTHORIZED ACCESS TO A NETWORK 

FIELD OF THE INVENTION 
5 The present invention relates to monitoring data traffic, 

and more particularly to identifying specific network data 
traffic intended to attack data ports and the like, as well as 
preventing the transmission of such attack data across the 
data ports. 

10 BACKGROUND OF THE INVENTION 

The increase of data traffic across the Internet, 
including the growth in the number of users of the Internet, 
as well as the number of merchants and businesses having a web 
presence, has resulted in a need to provide individualized 

15 management and monitoring of the data traffic flow. Merchants 
and businesses are realizing the increased need to monitor 
traffic flow, as the number of attacks on the web sites of 
these merchants and businesses has increased dramatically. 

The number of "hackers" continues to increase, and 

20 attacks on web sites are becoming a more common occurrence. 
Merchants and businesses are particularly concerned with 
obtrusive attacks on their web pages. In these attacks, 
"hackers" use all ports of a network system in an attempt to 
gain unauthorized access. Such attacks include for example 

25 denial of service (DoS) attacks (which include Buffer Overflow 
attacks, SYN attacks, Ping of Death attacks, Teardrop attacks 
and Smurf attacks) , which have potentially serious 
ramifications. DoS attacks attempt to shut down a network by 
flooding it with data traffic. These attacks attempt to 

30 exploit the limitations in the Transmission Control 
Protocol/Internet Protocol (TPC/IP) protocols and deprive the 
networks of resources, and can, in cases of large attacks, 
force a web site to temporarily cease operation. Such attacks 
can also destroy programming and files in a computer system. 

35 The "hackers" that attack these web sites are not necessarily 
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interested in obtaining confidential information from the web 
sites, but are interested in shutting down the sites by 
flooding a particular web-page with a large number of "hits," 
resulting in an overload of the server for the web site of the 
5 merchant or business . This results in an interruption in 
access to the site by consumers and essentially shuts down the 
web site, which for purely online businesses, is shutting down 
the entire business. For merchants and businesses that rely 
on the Internet for a large portion of their sales or for all 

10 of their sales, any period of non-operation is extremely 
costly, in both time and money. Other attacks include 
routing-based attacks and unauthorized access to certain 
protected services. 

Attempts have been made to develop systems to prevent 

15 unauthorized access to or from networks. Most commonly, 
firewalls are provided to control access to networks and 

i - 

,t S3. 

v- prevent access by unauthorized users. Essentially, these 

"~ firewalls are configured with a set of predetermined rules, 

0 which are usually static, and examine data traffic traversing 

20 the firewall to determine whether or not access should be 
(3 denied based upon the predetermined rules. Examples of 

f A firewalls include packet filers, which look at each packet 

£=l transmitted to a network to determine whether it should be 

L3 accepted or rejected based on a set of pre-defined rules; 

25 application gateways, which provide security to particular 
applications such as File Transfer Protocol (FTP) servers; 
circuit-level gateways, which provide security when certain 
connections, such as a TCP connection are established, 
thereafter allowing data packets to flow between hosts without 
30 further checking; and proxy servers, which capture all data 
packets entering or leaving a network, thereby hiding the true 
network addresses. These firewalls are typically used in 
connection with a network policy and other authentication 
mechanisms that define the set of rules. Also, these 

35 firewalls can be implemented by numerous devices, including 
routers, personal computers or Internet hosts. 
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Attacks on a network may occur from an outside source, 
but may also occur from a source within the network. 
Therefore, firewalls must provide for monitoring of traffic 
from both sides of the network. Even though networks rely on 
5 security methods other than firewalls to protect their 
systems, these methods do not always effectively protect the 
networks due to, for example, failure to update monitoring 
systems or complexity in the networks. This results in 
networks that are more susceptible to attack. A firewall adds 
10 to network protection and provides another line of defense 
against attacks. 

Although different types of firewalls exist, they are 
generally provided with static rules that limit the 
adaptability of the firewall. Also, these firewalls examine 

C3 15 each of the actual packets, which reduces data traffic 

-3 

Jl throughput, and generally only examine data traffic in one 

"""4 

Cn direction across network ports. Further, the firewalls 

typically deny access to and from an entire data port when 
detecting unauthorized data, instead of denying access to or 
3 20 from a single Internet Protocol (IP) address, which results in 

an unnecessarily broad denial of access. 
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SUMMARY OF THE INVENTION 

The present invention provides a device and method for 
protecting a network by monitoring data traffic transmitted 

25 from and received by a network using a non-promiscuous mode 
and preventing unauthorized access using dynamic rules, while 
maintaining network performance and minimizing administrative 
costs. The present invention monitors data traffic to detect 
unauthorized data packets, and thereafter denies access to 

30 unauthorized data packets. Essentially, data traffic patterns 
that exceed user configurable parameters is denied access to 
the monitored network. 

The invention is preferably provided as an intrusion 
detection system (IDS) using a packet daemon that captures, 

35 sorts, and catalogs network traffic on a packet-by-packet 
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basis. The packets are preferably captured for inspection by 
an interface, for example, by using available libpcap 
libraries. These libraries are further preferably used in 
connection with a parsing engine, which may be provided as a 
5 module that interfaces with the libpcap library (e.g., 
Practical Extraction and Reporting Language (Perl)). The 
combination results in a dynamically configurable firewall 
that can parse and trace network protocol hacking patterns 
using the capturing and parsing engines. 

The libpcap C library is a basic American National 
Standards Institute (ANSI) C code library that reads in 
network packets and provides basic software "hooks" or access 
points into various levels of package types including: 
physical data frames such as Ethernet, logical data frames 




15 such as Logical Link Control, connectionless datagrams such as 
User Datagram Protocol (UDP) , or stateful datagrams such as 



|H Transmission Control Protocol (TCP) . Perl is preferably used 

*Z to parse through the basic data packets or datagrams and strip 

,n off information that slows down the packet daemon. Perl also 

*3 20 preferably provides the source, destination, port, and 
protocol types for analysis and determination of attack 
I?** profiles. The packet daemon preferably uses this basic 

*2 protocol information collected from the packet headers to 

fj determine and issue firewall rules that provide the adaptive 

2^ firewall functionality. 
1 Specifically, the IDS with the packet daemon of the 

present invention, for use with, for example an adaptive 
firewall, copies data packets traversing ports of a network to 
determine whether access to or from a particular source should 
30 be denied. Preferably, one IDS having a packet daemon is 
provided for each port. In particular, a configuration file 
controls the parameters of operation, including for example 
sample rate. Based upon the security needs of the network, a 
data packet count threshold and a sample time are preferably 
35 provided to define the denial conditions for the network. In 
operation, if the number of packets from any one source 
exceeds the data packet count threshold during the sample 
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period, all data packets from that source to a specific 
destination are denied access to the network port. However, 
other data traffic can continue to access the network through 
that port. 

5 Thus, the present invention provides a method and device 

for monitoring network traffic that has adaptability and 
provides dynamic rule making. The preferred IDS in connection 
with a firewall also provides automatic denial of access to 
data packets meeting the denial conditions, which denial is 

LO removed after a lockout period, if the source is no longer 
transmitting attack data packets. The IDS with the packet 
daemon is preferably reset after the sample time and continues 
to monitor data traffic flow. 

The IDS may be provided as part of and integrated into a 

15 larger data traffic detection and monitoring system. 
Preferably, a separate IDS is activated for each monitored 
data port of, for example, a router. 

While the principal advantages and features of a present 
invention have been explained above, a more complete 

20 understanding of the invention may be attained by referring to 
the description of the preferred embodiments which follow. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram of a typical system in which 
the monitoring system constructed according to the principles 
25 of the present invention is implemented; 

Fig. 2 is a block diagram of the sorting and counting 
functions of the present invention; 

Fig. 3 is a block diagram illustrating an adaptive 
firewall operating in connection with an IDS and packet daemon 
30 constructed according to the principles of the present 
invention; 

Fig. 4 is a flow chart of the packet daemon algorithm of 
the present invention; 

Fig. 5 is a flow chart of a main thread of the present 
35 invention; 
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Fig. 6 is a flow chart of an ADS connections thread and a 
packet capture thread of the present invention; 

Fig. 7 is a flow chart of a per-second thread of the 
present invention; 
5 Fig. 8 is a flow chart of an increment count thread of 

the present invention; and 

Fig. 9 is a flow chart of a signal catching thread of the 
present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

10 A typical system in which the preferred embodiment of a 

data traffic monitoring system of the present invention for 
protecting networks may be implemented is shown schematically 
in Fig. 1 and indicated generally as reference numeral 50. As 
shown, the preferred monitoring system 50 may be provided by 

15 packet daemons (pktd) 52 as part of an IDS, which are provided 
as part of a firewall 54, with a separate packet daemon 
monitoring each port 56 or a network. The preferred firewall 
54 and packet daemons 52 may be provided in connection with a 
mid-network switching device, such as a router 58 which 

20 provides communication of data packets between the Internet 60 
and the internal network 62. In operation the router 58 
activates the specific IDS 52 associated with the ports 56 to 
be monitored. 

Although the monitoring system 5 0 is preferably 
25 implemented using packet daemons 52 and is shown as 
implemented in a router 58, it may be provided in connection 
with other components of a network to thereby monitor data 
traffic. The monitoring system 50 of the present invention is 
preferably provided as a software and hardware adaptive 
30 firewall 54 addition to, for example, a switch router 58, 
which detects and denies data traffic with patterns that are 
in contrast to normal traffic patterns (i.e., exceed user 
defined configurable parameters), thereby preventing hacking 
attacks on networks. Depending upon the security requirements 
35 of the network, the present invention may be configured to 
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detect different levels of attacks. The preferred packet 
daemon of the IDS 52 of the present invention uses the 
information it collects to issue firewall rules that make up 
the adaptive firewall functionality. 
5 The monitoring system 50 of the present invention is 

preferably provided in a multi- threaded design. This allows 
each thread to execute independently of the other threads, 
thereby increasing performance. Preferably, each thread 

shares the same data space with the other threads, resulting 

10 in simplified inter-process communication. Critical data 
, structure {e.g., packet information to analyze to determine if 

the packets exceed user defined parameters) are protected 
using semaphores, which also facilitate coordination and 
synchronization of the multi- threaded processes. 

15 In the most preferred embodiment, six threads handle the 

yg various functions of the monitoring system 50. Specifically, 

the following threads are preferably provided: (l)Main Thread: 

■CP 

^ initializes IDS data structures, activates the other threads, 

«P and waits for the other threads to complete their processes; 

'/J 20 (2) ADS connections thread: sends buffers to ADS, if ADS is 

| 3 present; (3) Packet Capture Thread: processes each packet, 

updates hit counts, queues lockout start commands to the per- 
second thread, extracts various fields, buffers the fields for 
tp transmission to an Anomaly Detection System (ADS) , and 

rf 25 notifies ADS connection thread to send buffers; (4) Per-second 
thread: runs each second, starts and stops lockout periods, 
and clears "hit" count table as configured; (5) Increment count 
thread: to determine a lock-out condition; and (6) Signal 
Catching Thread: re-reads configuration file, handles IDS 52 
30 process cleanup and termination. 

More specifically, the main thread is indicated generally 
as 300 in Fig. 5. This thread determines whether any special 
instructions are required to be processed at the read config 
step 302. The signal catching thread is then activated at the 
35 start signal thread step 304. At the start ADS connections 
step 306, the ADS connections thread is activated. The packet 
capture thread is then activated at the start capture thread 
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step 308. Then, the per-second thread is activated at the 
start per-second thread step 310. Once activated by these 
threads, the IDS 50 remains active until otherwise instructed. 

The ADS connections thread 320, as shown in Fig. 6, 
5 determines whether connection to the ADS is required at step 
322, and if so, a "flag" is set at step 324. The capture 
buffer then waits at step 326 before writing to the ADS at 
step 328 until instructed by the packet capture thread 350 
that the capture buffer is full. If the write to the capture 

10 buffer is activated and completed successfully, the ADS 
connections thread 320 waits for another command from the 
packet capture thread 350 to write to the capture buffer. If 
an error 330 is received, then preferably a five second delay 
is provided and the ADS connections thread 320 determines 

15 whether connection to the ADS is required at 322. If no error 
is received, the ADS connection thread returns procedurally 
along arrow 331 to the capture buffer step 326. 

With respect to the packet capture thread 350 as shown in 
Fig. 6, the packet capture function is enabled at step 3 52. 

20 When a new data packet is received with a new header at step 
3 54, the necessary header information as described herein is 
collected at step 356. Essentially, a hook from the Lib PCap 
library provides an indication when a new data packet received 
and header data needs to be collected. Therefore, the packet 

25 capture thread 350 waits until a packet is received, which is 
preferably provided as a call-back function, and thereafter 
collects the necessary header information at step 356. The 
packet capture thread at step 3 58 determines whether the 
particular source and destination address pair are already 

30 provided a count value in a hash table. If yes, the value is 
incremented by one at step 360. If not, an entry is created 
at step 362 with the initial count preferably set at one. The 
count function is preferably provided by the increment count 
thread 400 shown in Fig. 8. This thread determines whether 

35 the count exceeds a predetermined limit or threshold at step 
402. If the limit has not been exceeded, then the increment 
count thread is done. If the count exceeds the limit or 
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threshold, then at step 404 a lockout command is added to the 
chains list. 

Then, preferably, if the ADS flag is set at step 362, 
which flag is set by the ADS connections thread 320, packet 
5 data is added to the capture buffer at step 364. If the 
buffer is not full at step 366, then the packet capture thread 
350 waits for a new data packet. If the capture buffer is 
full, then the ADS connections thread 320 is notified at the 
capture buffer ready step 32 6, and the data is written to the 

10 ADS at 328. Preferably, multiple capture buffers are 

provided, such that one capture buffer is writing to the ADS 
while another is receiving new header information. 

The per-second thread 3 80, as shown in Fig. 7, determines 
whether the sample period has ended at step 382. The default 

15 sample period is preferably ten seconds. If the sample period 
has ended, the hash table is reset (i.e., all values with 
respect to the count for any source and destination address 
pair is cleared) . If the sample period has not expired, then 
at step 384 a determination is made as to whether any lockouts 

20 have expired. If any lockouts have expired, then at step 386; 
a remove lockout command is added to a chains-list. The 
default period of lockout for a source and destination address 
pair is preferably twenty minutes. Thereafter, or if no 
lockouts have expired, the per-second thread 3 80 determines at 

25 step 3 88 whether any commands in the chains list are 
outstanding. These commands include, for example, a new 
lockout command from the increment count thread 400 or a 
remove lockout command from the per-second thread 380. If 
yes, then at step 390 the chain commands are executed. If no, 

30 then a one second delay is preferably provided at step 392 and 
a determination is again made at step 3 82 as to whether a 
sample period has ended. 

With respect to the signal catching thread 420 as shown 
in Fig. 9, the thread waits for signal at step 422. This 

35 signal is preferably a UNIX signal. If a hang-up (HOP) signal 
is received, then at step 424 a new configuration file is read 
by the IDS 50. This includes if a user changes the settable 
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parameters, such as for example the count threshold or sample 
period- The signal catching thread 420 at step 426 determines 
whether a kill signal has been received. If yes, then a 
determination is made at step 428 as to whether any lockouts 
5 exist, and if yes, the lockouts are removed at step 430, all 
threads are deactivated at step 432, and the IDS 50 is thereby 
deactivated as step 434. If no kill command is received, the 
signal catching thread 420 waits for another signal at step 
422 . 

10 Thus, the present invention provides for monitoring or 

listening to all traffic on a particular physical network 
interface. As described herein, the monitoring system 50 of 
the present invention is preferably provided as an IDS having 
a packet daemon 52, thereby allowing it to work in the 

15 background performing the specified operation at predefined 
times, while transferring data to smaller programs for 
processing. A packet daemon 52 as part of an IDS is 
preferably provided at each port of the interface and is 
preferably configurable by a specific configuration file that 

20 controls the operation and monitoring processes of the packet 
daemon. This configuration file controls specific parameters 
of the packet daemon 52, including for example sample rate, 
logging, and lock-down rate. 

As shown in Fig. 1, a plurality of multi-threaded packet 

25 daemons 52 as described herein are preferably provided when a 
device, such as a router 58 has multiple interfaces or ports 
56. The preferred IDS is therefore preferably non- 

promiscuous. In operation, when a particular IDS 52 is 
activated with an associated packet daemon for a particular 

30 port 56, preferably only data packets destined for the 
particular port's 56 hardware MAC address are captured. In 
the most preferred embodiment, IP and Address Resolution 
Protocol (ARP) data packets are captured by the packet capture 
thread 3 50 and processed by the packet daemon of the IDS 52 to 

35 determine if the data packets are allowed access to the 
network. Specifically, with respect to the packet daemons, 
each preferably reads from the data traffic stream of its port 



10 



i % 

every millisecond. The packet daemons sort, count and catalog 
individual packets, and associated information, depending upon 
the configuration of the web-interface and the requirements of 
the network, as described herein. Preferably, the sorting and 
5 counting of data packets occurs in Random Access Memory (RAM) 
memory, while the cataloging of data packets is written to a 
solid-state disk with an access time of preferably .01 
milliseconds or less, which is then preferably provided to a 
relational database management system (RDBMS) . The RDBMS 

10 allows for the creation, updating and administering of a 
relational database. 

It should be noted that any processing of data packet 
information is performed on copies of the data packets so as 
to maintain throughput of data traffic. More preferably, only 

15 the data packet header is captured from a captured packet and 
copied for processing. Preferably, specific fields of 

interest are extracted from the header by the packet capture 
thread 3 50 to determine whether the data should be denied 
access, using the per-second thread 3 80 and the increment 

20 count thread 400. In one embodiment an Anomaly Detection 
System (ADS) is provided and the extracted header fields are 
separately buffered and periodically transmitted to the ADS by 
the ADS connections thread 320 at step 328. In another 
embodiment, the ADS is not provided and the buffering process 

25 is disabled. 

In operation, when the ADS is provided, the IDS 
preferably automatically establishes communication with the 
ADS in each instance when the ADS is activated. With the ADS 
activated, the following fields are preferably extracted from 

30 the packet header for processing: (1) Ethernet type; (2) 
source and destination MAC addresses; (3) source and 
destination IP addresses; (4) protocol type; (5) source and 
destination ports (only for IP protocols TCP and UDP) ; and (6) 
packet length. 

35 Referring now to Fig. 2, and the operation of the 

preferred packet daemon of the IDS, the preferred packet 
daemon creates memory references to each packet source Media 
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Access Control (MAC ) address in a hash table, wherein keys 
(which are the part or group of the data by which it is 
sorted, indexed and cataloged), are mapped to array positions. 
As a result of sorting in memory (i.e., processing copies of 
5 the data packets) , each dedicated packet daemon can sort 
packet counts on each port at near real-time speed. 

A "hit-count" table is preferably created in memory to 
count the number of times a particular pair of source and 
destination IP addresses is detected. Entries are stored 

; 10 using a hash table, keyed by the source and destination 

addresses. In operation, if the "hit" count exceeds a 

configurable threshold, all traffic between the source and 
destination endpoints is disabled for a configurable lockout 

! period. When the lockout period ends, traffic between the 

□ 15 endpoints is re-enabled. The IDS of the monitoring system 50 
preferably generates a system log message when a lockout 

f?l period begins or ends . 

r* The "hit-count" table is preferably cleared after a 

[Z configurable sample period has elapsed by the per-second 

S Q 20 thread 380. The sample period default may be, for example, 
^ ten seconds. It should be noted that clearing the "hit-count" 

^ table does not affect any lockouts currently in progress. 

^ With respect more specifically to the "hit-count" table, 

Zz. each time a data packet is received, a preferred algorithm as 

:= i 25 described herein creates a new reference index (if one does 
not already exist) or increments the existing reference (i.e., 
counting packets). For example, as shown at 100 in Fig. 2, 
the packet daemon identifies the packet source address 
qwl232ewr23 and at 102 creates a memory reference (memref) for 
30 that source address. At 104 the packet daemon identifies the 
source address of the next data packet traversing the port 
being monitored by the packet daemon, in Fig. 2, the source 
address being mg32ewr009 . At 106 another memref is created 
for this source address. Therefore, at 104 each of the 
35 memref s are equal to 1, representing that one data packet from 
each of the sources identified has traversed the data port of 
interest. At 108, another packet from source address 



12 



% % 



qwl23ewr23 is identified, and as shown at 110, the 
corresponding memref for that address is incremented. So, if 
for example the threshold data packet value is 1000 for the 
sample time (e.g., 10 milliseconds), and source address 
5 qwl232ewr23 exceeds the threshold in this period (e.g., memref 
qwl232wer23=1001 ) , then access to the port being monitored 
will be denied to packets from that source. It should be 
noted that the source may be transmitting from either outside 
or inside the network. 

10 The preferred algorithm continues cataloging packets in 

connection with a specific packet daemon until a user-defined 
sample time set in the packet daemon configuration file 
expires. After the sample time expires, the memref, as shown 
in Fig. 2, is preferably reset (e.g., qwl232ewr23 = 0 ) and the 

15 process again monitors the port for attack profiles based upon 
the system defined parameters, such as the count number of 
data packets from a single source. 

With respect specifically to cataloging, such process 
occurs only if the system's logging is enabled. If enabled, 

20 the cataloging function preferably creates a small ASCII file 
which provides information captured from the data packets, 
including for example source and destination MAC addresses and 
IP Addresses, packet type, packet size and destination port. 
This file is preferably transmitted using a secure channel on 

25 a short-time based interval to a large RDBMS . 

Sorting of data is preferably provided using a relational 
model that can sort data with the following keys: 

• Source Address 

• Destination Address 
30 • Source MAC Address 

• Source Destination Address 

• Protocol Type 

• Time/ date stamp 

Using these primary data types, the present invention can sort 
35 data type attacks and protocol types to identify new patterns, 
as well as catalog usage patterns and usage profiles. Using 

13 
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the keys, a hash table can be created to monitor for and 
determine data attack types depending upon the particular 
security needs of the network. 

Within a router having the IDS 52 with the packet daemon, 
5 during operation the packet capture overhead could reduce 
performance. Preferably, the IDS overhead is configurable to 
provide a delay for a predetermined period of time after 
capturing a specified number of packets. For example, after 
capturing 10,000 data packets, a 10 millisecond may be 

10 provided before again capturing data packets. 

As shown in Fig. 3, an adaptive firewall 54 preferably 
operates in connection with the sorting and counting 
procedures of the packet daemon in a router 58. The adaptive 
firewall is preferably not dependent on a rules based 

15 mechanism that has a statically configured monitoring and 
defense model. These rules would then require modifying and 
updating to monitor and identify new types of attacks and 
different attack profiles. The adaptive firewall of the 
present invention has no "preprogrammed" rules that must be 

20 designed to a specific pattern, and thus the network 
administrator does not have to constantly ensure that the 
rules are current. The preferred adaptive firewall for use in 
connection with the present invention must only be provided 
with two parameters to perform its monitoring operations: a 

25 data packet count threshold and a sample time. 

The parameters for the adaptive firewall may be provided 
by, for example, the network system administrator based upon 
the security policy of that network. The network 

administrator provides a threshold data packet count value, 

30 which represents the maximum number of packets per sample 
time, and if the number of packets from any one source exceeds 
the data packet threshold value during the pre-determined 
sample time, as described above, all data packets from that 
source will be denied. However, the physical network port 

35 preferably remains open for the other data traffic. It should 
be noted that the denial to the specific source address is 
preferably automatic, and will be removed only after a pre- 
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defined lockout period, and only if the transmission of the 
attacker's traffic has subsided. Preferably, the system 
provided by the present invention continues to monitor the 
data ports for data packets from the denied source to 
5 determine whether it is in conformance with the predetermined 
rules based on the sample time and data packet threshold 
value. Only if the source meets the network rules, and the 
lockout period (e.g., 20 minutes) has expired, will the 
network allow transmission of data packets to and from the 

10 previously denied source. 

With respect specifically to the "hit-count" table, the 
following data structures are provided: (1) Lockout start 
command queue: for communication between the packet capture 
thread 352 and the per-second thread 380. It contains the 

15 source and destination IP address pair to be blacked, out; (2) 
In-progress lockout list: list of in-progress lockouts. 
Contains the locked-out source and destination IP address 
pair, along with the time that the lockout will end; and (3) 
ADS buffer pool: contains buffers to be filled by the packet- 

20 capture thread 350 for transmission to ADS. 

Referring again to Fig. 3, the data packet count 
threshold is set at 1000 with a sample time of ten 
milliseconds. As illustrated, the current time is t=5 

milliseconds, with data packets from Address (Addr) 5 and Addr 

25 7 violating the denial conditions (i.e., greater than 1000 
data packets transmitted in ten milliseconds) . Therefore, 
data packets from Addr 5 and Addr 7 are denied access, while 
data packets from all other source addresses are permitted to 
transmit through the router 58. 

30 Referring now to Fig. 4, the preferred packet daemon 

algorithm loops until certain predetermined conditions are met 
and the process does not exit unless the network administrator 
configures it for shutdown. As illustrated in Fig. 4, at 200 
the packet daemon is activated or enabled which begins the 

35 process of monitoring network data packets 202. If logging is 
enabled as shown at 204, a log file is preferably created at 
206 with data from the network packet transmitted and stored 
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in the RDBMS at 208. A report may be provided as needed at 
210. If logging is enabled, information from each network 
packet is stored in the RDMBS . It should be noted that these 
functions are provided by the multi- threaded IDS 50. 
5 Referring again to the main operation of the packet 

daemon (i.e., after logging is performed or if logging is not 
enabled) , at 212 the packet data is identified using the 
packet capture thread 3 50, including storing of the source 
address for that packet at a memref location. This memref is 

10 preferably a pointer to a software memory location. The 
algorithm then determines whether the threshold data packets 
count has been met at 214 using the increment count thread 400 
and per-second thread 380. If not, no further action is 
required and data packets continue to be read by the packet 

15 daemon. If the threshold has been met, then at 216 the 
adaptive firewall is executed (i.e., the network denies access 
to data packets from the source exceeding the threshold value) 
using the per-second thread 380 and increment count thread 
400. Essentially, the network will block data packets from 

20 the denied source through the ports of the network while the 
source is transmitting packets that exceed the predetermined 
threshold value. At 218, the algorithm determines whether the 
network intruder is still attacking (i.e., is the denied 
source address still transmitting data packets across the 

25 monitored port) using the packet capture thread 3 50 and pre- 
second thread 380. The preferred system continues to monitor 
and count the number of data packets being transmitted from 
the denied source using the increment count thread 400. If 
the intruder (which may be an internal or external intruder) 

30 is still transmitting in violation of the predetermined rules, 
then the firewall continues to deny access to data packets 
from that source. If the intruder is not transmitting, or is 
now transmitting within the threshold limits, then at 220, the 
rule is removed (i.e., denial is removed) using the per-second 

35 thread 380. However, the system administrator may decide that 
regardless of whether transmission from the denied source has 
terminated, no data packets from that source should be allowed 
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access for a predetermined period of time (i.e., a lockout). 
If this is the case, then denial of access is continued at 216 
until the expiration of this period. If the memrefs have not 
been reset during the period of denial, then only the memref 
5 for the denied source address will be reset at 220. 

With respect specifically to the configurable parameters 
of the monitoring system 50, the following are preferably 
provided: (1) packet capture overhead tunables: number of 
packets to capture before delaying and length of delay in 

10 milliseconds; (2) lockout tunables : sample period in seconds, 
"hit" count threshold, and length of lockout period in 
seconds; and (3) ADS connection: IP address and TCP port. 

There are other various changes and modifications which 
may be made to the particular embodiments of the invention 

15 described herein, as recognized by those skilled in the art. 
However, such changes and modifications of the invention may 
be constructed without departing from the scope of the 
invention. Thus, the invention should be limited only by the 
scope of the claims appended hereto, and their equivalents. 
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